ERP 用了十年、二十年，訂單照樣能開，庫存、財務也都還在正常作業。這時候如果有人提出要做現代化，我想，大家最先問的應該是：

現在明明還能用，為什麼還要改？

這也是我想用這 30 篇文章，慢慢整理清楚的問題。

其實，把周邊需求一項一項列出來，就比較容易理解了。電商要查庫存，子公司要接訂單，供應商與 EDI 要交換資料，每一個需求背後又都有權限、效能與追查問題的要求。後續如果再加入 AI 與 RAG，ERP 要照顧的事情只會更多。

我對 ERP 現代化的期待很單純：把已經穩定運作的核心交易保留下來，再一步一步補上管理入口、追蹤問題與驗證變更的能力。過程中，既有作業要能繼續，新功能出了問題，也要知道怎麼退回去。

所以，這個系列會從轉型策略開始，接著談服務邊界、ERP 整合、身分授權與事件處理，再走到可觀測性、AI 治理和變更追溯。我想把每個選擇的原因、做法與限制一起寫下來，讓這份整理能成為後續實作時的參考。

本篇名詞小筆記

• ERP：企業資源規劃（Enterprise Resource Planning），用來整合訂單、庫存、採購、財務等核心作業。
• API：應用程式介面（Application Programming Interface），讓不同系統依約定格式交換資料與功能。
• EDI：電子資料交換（Electronic Data Interchange），讓企業與合作夥伴依固定格式交換訂單、出貨等商業文件。
• RAG：檢索增強生成（Retrieval-Augmented Generation），先找出相關資料，再交由語言模型依資料產生回答。

今天要解決的問題

討論舊 ERP 是否需要調整時，常會聽到這個說法：

只要 ERP 還能跑，就沒有現代化的必要。

ERP 還能穩定處理交易，我認為這是值得保留的能力。接下來要想的，是新需求接不接得進來，以及接進來之後，有沒有人能持續維護。

以製造業的物料、訂單與庫存查詢為例，常見的處理方式包括：

• 直接查詢 ERP 資料庫；
• 複製既有 SOAP 介面；
• 在 ERP 內增加一支客製程式；
• 由各系統自行處理帳號、權限與錯誤；
• 發生問題時，再分別檢查各主機的 Log。

這些做法都能解決一部分需求。只是，當串接的系統越來越多，我會特別留意下面四件事。

1. 耦合持續增加

呼叫端如果直接使用 ERP 的資料表、欄位與 SOAP 格式，ERP 一調整，就得找出所有相關系統一起改、一起測。串接越多，這份確認工作也會跟著增加。

2. 安全與權限散落

帳號、角色與規則各自管理，異動時就容易漏掉一個地方。等到要查誰在什麼時間看過哪些資料，又得把各系統的紀錄重新整理起來。

3. 問題難以定位

一筆訂單可能走過前端、API、ERP、訊息系統與外部夥伴。如果 Log、Metric 與 Trace 接不起來，就只能一站一站找，花在確認問題的時間也會拉長。

4. 每次交付都牽動核心

有時只是新增一個 API，也需要改 ERP、調排程，再等共同上線。核心作業要穩定，周邊需求也要往前走，哪些地方可以分開變更，就值得先整理。

整理到這裡，我會先把問題放在介接方式上：新需求要怎麼取得 ERP 的能力？這條路徑又由誰管理？

架構師視角：保留核心，隔離變化

這個系列的分工，我想先用一句話說明：

ERP 繼續負責穩定交易，現代化平台負責應對外部變化。

圖 Day 01-1：ERP 現代化平台。

有了這張圖，還要把每一層的工作說清楚。SOAP 能轉成 REST，是其中一步；下面這些責任，也要有方法接起來。

這類在不同語意與領域模型之間建立轉換層的做法，可用 Anti-Corruption Layer（ACL，舊系統語意隔離層） 說明。Eric Evans 在《Domain-Driven Design》中提出這個概念，Microsoft Azure Architecture Center 也將它整理成架構模式。在本系列的情境中，就是把舊系統的資料模型、介面格式與通訊協定限制，集中在明確的轉換範圍內。

移轉方式則可搭配 Martin Fowler 所介紹的 Strangler Fig Pattern。讓新舊系統先並存，再逐項移轉流量與業務能力，每次移轉都保留驗證與回退的機會。

工程師視角：第一步不是建立十個服務

Gateway、Kafka、Kubernetes，都是討論架構時很容易出現的名字。不過，每多一個元件，後面就多了部署、監控與維護的工作。因此，我會先問自己：現在加進來，是要解決哪個問題？

所以，第一步我會先做盤點。線上服務、排程、外部介面，凡是有直接依賴 ERP 的，都先列出來。

ERP 依賴清冊至少應包含以下欄位：

清單整理好之後，再挑一條範圍清楚的流程開始。例如先讓物料查詢經過 Gateway 與 Adapter，實際走完一次，確認基本能力都接得起來，再往交易比較複雜的地方前進。

第一條流程的驗證範圍，至少包含以下六項：

1. 呼叫是否統一經過入口？
2. 身分與權限是否能被驗證？
3. 新服務是否不必理解 SOAP 細節？
4. ERP 異常是否能轉成一致的錯誤格式？
5. 一筆請求是否能從入口追蹤到 ERP？
6. 新平台故障時，是否有清楚的回退方式？

常見反例：跳過盤點，先建立平台

這裡可以想像一個情況：Gateway 與 Adapter 都建好了，新的需求也開始走平台，但舊介面還沒有盤點完。

此時若還有排程直接寫入 ERP 資料庫，或外部夥伴持續呼叫舊 SOAP 端點，同一份資料就可能存在兩條寫入路徑。資料對不上時，新平台的紀錄也無法涵蓋舊路徑，仍需要另外追查。

這也是為什麼我會把治理涵蓋率放進驗收。新入口能用之後，還要回頭看看：哪些舊路徑已經收回來？哪些還在使用？剩下的工作由誰處理，預計什麼時候完成？

策略取捨與限制

多了平台，整合工作還是要做，只是改由平台集中處理。這部分要花的人力與時間，也要一開始就算進去。

評估時應一併列入以下成本與處理條件：

如果團隊規模不大，我會先考慮模組化單體，或從少量服務開始。先把分工和基本維運做好，之後真的有獨立部署或擴充的需要，再繼續拆分，也是一條可以走的路。

驗證方式與衡量指標

現在花多少時間、多少系統還在直連 ERP，都還不知道。所以第一天，我想先把現況量起來，改善百分比可以先不急著寫。

之後每完成一部分，就回來和這份紀錄比一比。問題有沒有改善？多出來的成本能不能接受？這樣才知道下一步該往哪裡走。

今天先整理到這裡

回頭看今天的內容，我認為最先要做好的，就是把 ERP 繼續負責的交易，以及周邊需要補上的能力分清楚。

核心功能先穩定保留，再逐步整理入口、服務分工、ERP 隔離層、身分與可觀測性。每一步都確認誰負責、怎麼驗證，以及出問題時怎麼回退，才能安心往下做。

下一篇，我想把這些想法整理成一張 ERP 現代化策略矩陣。從現況、策略到風險與指標，放在一起看，也比較容易決定先做哪一件事。

參考資料

1. Microsoft Azure Architecture Center, Strangler Fig pattern，查閱日期：2026-09-14。
2. Microsoft Azure Architecture Center, Anti-Corruption Layer pattern，查閱日期：2026-09-14。
3. Martin Fowler, Strangler Fig Application，查閱日期：2026-09-14。
4. Microsoft Azure Architecture Center, Microservices architecture style，查閱日期：2026-09-14。